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Requirements for IETF Nominations Committee Tools 


Abstract 


This document defines the requirements for a set of tools for use by 
the IETF Nominations Committee. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any 
errata, and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6730. 


Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The IETF Nominations Committee (NomCom) is a body that selects 
candidates for open IESG, IAB, and IAOC positions following the 
process outlined in [RFC3777]. There is a need for a set of tools to 
aid the NomCom in efficient operation. This document presents a set 
of requirements for such a tool. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Meta Requirement 


There is an existing tool for supporting NomCom work. The set of 
requirements specified in this document are mainly enhancement 
requirements or behavioral changes to the existing tool. Unless 
otherwise stated, all of the current functions of the existing NomCom 
tool need to be supported in the new tool as well. 


o META-001: The tool MUST provide all the functionality that is 
provided by the current NomCom tool, except in cases where a 
requirement specified in this document overrides a current 
behavior. The current NomCom tool can be found at the following 
URLs: https://www.ietf.org/group/nomcom/2012/private/ displays the 
NomCom private parts of the tool (Private NomCom tool) and 
https://www.ietf.org/group/nomcom/2012/ displays the community 
member accessible parts of the tool (Public NomCom tool). 
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3. Authentication 


All access to NomCom tools needs to be authenticated. Users of the 
tools have different privileges based on their role. The tool needs 
to support at least three levels of access: community member, NomCom 
member, and NomCom chair. The levels of access are set up by the 
staff of the IETF Secretariat. It is to be noted that the 
Secretariat staff do not have any access to the tool. They are 
responsible for administering the server on which the tool runs; 
hence, they set up the access control list for the tool. 


Community member access is applicable to the Public NomCom tool. The 
NomCom member access and the NomCom chair access are applicable to 
the Private NomCom tool. NomCom members can use the interfaces on 
the Public NomCom tool in the community member role. The NomCom 
chair access authentication applies to the private webpage in the 
same fashion as a NomCom member, with the additional ability to 
update the information on both webpages (i.e., what is visible in the 
various forms, the templates for the automatic emails, etc.). 


Oo AUTH-001: The tool MUST allow members of the community to log in 
with their existing datatracker.ietf.org credentials. 


o AUTH-002: The tool MUST allow members of the community to create a 
new login using the datatracker.ietf.org login system. 


o AUTH-003: The tool MUST allow the secretariat to enter the email 
address of the NomCom chair and to enter a list of email addresses 
of the NomCom members. The logins associated with these email 
addresses MUST be accorded the respective roles. 


4. Security and Access Control 


All communication between the community and the NomCom and amongst 
the members of the NomCom needs to be stored in an encrypted form. 
This information can only be accessed by members of the NomCom. 


o SEC-001: The security procedures for the tool MUST be structured 
so that even system administrators do not have routine or 
accidental visibility to any data accumulated by the tool. This 
data includes all confidential feedback and discussions. 


o SEC-002: The tool MUST allow the NomCom chair to input a public 
key ("NomCom public key"). This key is generated by the NomCom 
chair independent of the tool, for example, using the procedure 
described in Appendix A. 


Krishnan & Halpern Informational [Page 3] 


RFC 6730 NomCom Tools September 2012 


S 


o SEC-003: All communication sent to the NomCom mailing list MUST be 
encrypted with the NomCom public key before being committed to 
persistent storage. 


o SEC-004: All community feedback entered using the NomCom tool MUST 
be encrypted with the NomCom public key before being committed to 
persistent storage. 


o SEC-005: After logging in, the tool MUST allow the NomCom members 
to input a private key ("NomCom private key") that corresponds to 
the NomCom public key. This key will be used to decrypt the 
feedback/communications that the member is trying to access. Once 
entered, this key MUST be available for the entire length of the 
session until the user logs out. This private key MUST NOT be 
stored in plaintext form into persistent storage at any point of 
time. 


o SEC-006: The tool MUST provide a mechanism for the NomCom Chair to 
destroy all data collected by the NomCom at the end of the 
NomCom’s term. Since the NomCom’s term overlaps with that of the 
next year’s NomCom, the tool MUST ensure that data collected by 
the next year’s NomCom is not affected by this deletion. 


Nominations 


After the NomCom is constituted, the NomCom chair issues a call for 
nominations for the open positions. There are two broad ways in 
which nominees are introduced into the system. The predominant way 
is that nominations are entered into the system directly by members 
of the community. The secondary way is that the nominees are entered 
in by members of the NomCom. The main difference is that members of 
the NomCom can enter nominations that are originated by other 
community members. In both of the cases, an email address for the 
nominee needs to be entered into the tool. Please note that NomCom 
members usually use the Public NomCom tool, not the Private NomCom 
tool, to enter their personal nominations and comments. 


o NOM-001: The tool MUST allow members of the community to enter 
nominations into the Public NomCom tool. 


o NOM-002: The tool MUST allow members of the NomCom to enter 
nominations into the Private NomCom tool. The tool MUST allow the 
NomCom member to optionally enter information about the originator 
of the nomination. The tool MUST record the identity of the 
originator (if known) of the nomination for audit purposes. Note 
that anonymous nominations are allowed; thus, the actual identity 
of an originator may not always be entered into the tool. 
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o NOM-003: The tool MUST allow the NomCom chair to specify 
information that is required for the nominations. This 
information will be entered by the NomCom chair as freeform text 
and will be presented to the individual performing the nomination. 


o NOM-004: The tool MUST email the nominee after the nomination and 
mention the position(s) that they have been nominated for. This 
email MUST NOT disclose to the nominee the identity of the person 
who performed the nomination. 


o NOM-005: The tool MUST allow the content of this email to be 
customized by the NomCom chair. 


o NOM-006: The tool MUST automatically attach the questionnaires for 
the positions for which the nominee has been nominated to this 
email. 


o NOM-007: The tool MUST be able to identify duplicate nominations 
of the same person with the same email address and consolidate 
them to point to the same nominee. 


o NOM-008: In case the same person has been nominated multiple times 
using different email addresses, the tool MUST allow the NomCom 
chair to mark duplicate nominations of the same person and 
consolidate them to point to the same nominee. 


o NOM-009: The tool MUST allow a communication email address for a 
nominee to be set to one different than the email address with 
which they were nominated. 


o NOM-010: The tool MUST be able to use the datatracker address book 
system as the basis for requirements NOM-007, NOM-008, and NOM-009 
but MUST allow the NomCom chair to perform manual overrides. 


o NOM-011: The tool MUST keep track of the accept and decline status 
for the nominees. 


6. Accepting and Declining Nominations 


After receiving the nomination mail, nominees usually respond to 
indicate either that they accept the nomination or that they are 
unwilling to do so. 


o AD-001: The tool MUST allow nominees to indicate whether they are 
accepting or declining their nomination. This is preferably done 
by providing distinct hyperlinks in the email that the nominees 
receive. 
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o AD-002: The tool MUST allow the NomCom chair to select specific 
email responses from the nominees and flag them as having been 
accepted or declined. 


o AD-003: The tool MUST allow the NomCom chair to manually flag 
nominees as having accepted or declined the nomination without the 
need for any nominee action. 


o AD-004: The tool MUST allow NomCom members to view the list of all 
nominees along with their accept or decline status. 


o AD-005: The tool MUST allow NomCom members to view reports of the 
accept or decline status both per nominee as well as per open 
position. 


o AD-006: The tool MUST be configurable to send reminder mails to 
all nominees who have not responded, either on specified dates or 
at specified intervals. The contents of the reminder mails MUST 
be customizable by the NomCom chair. 


o AD-007: The tool MUST be able to generate a summary report 
containing statistics (total/accept/decline/no response) 
concerning nominations by position. 


7. Questionnaires 


Nominees fill in a questionnaire for each position for which they 
accept a nomination. The completed questionnaire is sent in by email 
to the NomCom mailing list. If a person has been nominated for 
multiple positions, they may elect to send in a combined 
questionnaire for a subset (or all) of the positions (QR-002) or fill 
in one questionnaire per open position (QR-006). 


o QR-001: The tool MUST allow the NomCom chair to enter a different 
questionnaire for each open position. 


o QR-002: The tool MUST allow the NomCom chair to point to email 
responses from the nominees and flag them as questionnaires. 


o QR-003: The tool MUST allow NomCom members to directly access 
questionnaires completed by nominees. 


o QR-004: The tool MUST keep track of the questionnaire receipt 
status for the nominees. The completed questionnaires are 
received as emails to the NomCom mailing list. 
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8. 


QR-005: Like all other correspondence on the NomCom mailing list, 
the completed questionnaires MUST be encrypted by the NomCom 
public key before being stored. 


QR-006: The NomCom chair MUST be able to flag an email as the 
completed questionnaire for a nominee corresponding to a specific 
open position. 


QR-007: Once flagged, the questionnaire provided by the nominee 
for a specific position MUST be directly accessible without 
needing to look through all other feedback received for that 
nominee. 


Feedback Collection 


Community feedback is very important in the NomCom process. 
Community feedback about nominees is the primary mechanism by which 
NomCom members evaluate nominees. 


(0) 


FB-001: The tool MUST allow members of the community to enter 
feedback about any of the accepting nominees into the Public 
NomCom tool. 


FB-002: The tool MUST allow members of the NomCom to enter 
feedback about any of the accepting nominees into the Private 
NomCom tool. The tool MUST allow the NomCom member to optionally 
enter information about the originator of the feedback. Note 
that, as in NOM-002, anonymous feedback is allowed; thus, the 
actual identity of an originator may not always be entered into 
the tool. 


FB-003: The tool MUST allow NomCom members to view feedback 
entered for each nominee. The identity of the submitter should 
also be visible with the feedback, unless the submitter wishes to 
be anonymous. 


FB-004: The NomCom members MUST be able to enter their interview 
comments as feedback for the nominee being interviewed. 


FB-005: All email received on the NomCom mailing list MUST be 
archived. This includes all correspondence among the NomCom 
members, feedback received over email, as well as completed 
questionnaires. 
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o FB-006: The tool MUST allow the NomCom chair to manually copy any 
of the archived mails into the feedback section of one or more 
nominees for one or more open positions. This is required because 
a single email may contain feedback concerning more than one 
nominee or more than one open position. 


9. Security Considerations 


The tool must authenticate all users and must allow logins to be 
classified into three roles: NomCom chair, NomCom member, and 
community member. All communications to/from the NomCom and among 
members of the NomCom must be stored in an encrypted form. 
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Appendix A. Example for Key Generation 


September 2012 


The NomCom chair generates a public/private key pair to be used to 
encrypt NomCom correspondence and feedback. As an example, the 
NomCom chair can use openssl to generate the key pair using the 


following commands: 


First, the config file for openssl needs to be created with the 
following contents (example for the 2012-2013 NomCom). 


[ req ] 

distinguished_name = req_distinguished_name 
string_mask = utf8only 
x509_extensions = SS_v3_ca 


[ req_distinguished_name ] 


commonName = Common Name (e.g., NomComyYY) 
commonName_default = NomCom12 
[ ss_v3_ca ] 


subjectKeyIdentifier = hash 

keyUsage = critical, digitalSignature, keyEncipherment, 
basicConstraints = critical, CA:true 

subjectAltName = email:nomcoml12@ietf.org 
extendedKeyUsage= emailProtection 


# modify the email address to match the year. 


Figure 1: nomcom-config.cnf 


dataEncipherment 


Then the following command needs to be issued in order to generate 


the private key and the certificate. 


$ openssl req -config nomcom-config.cnf -x509 -new -newkey rsa:2048 
-sha256 -days 730 -nodes -keyout privateKey.pem -out nomcoml2.cert 


The certificate can then be provided to the tool in order to extract 


the public key. 
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